The AVATAR I Expert System ---------------------------- LEVEL 1 ------- Public Domain Version 2.01 LIMIT: 50 Rules --------------- (A version of this program with that capability of holding up to 10,000 Rules including a User Run-Time inference engine, Expanded Manual and Tutorial is available for $35.00 (in the U.S.- add $10.00 for shipping to other countries) from Essence AI-AMC Publishing at the address below. See Appendix for list of other levels' capability.) Essence AI-AMC Publishing Telephone: (503) 644 - 2438 P.O. Box 1420 Beaverton, OR 97075-1420 Copyright 1988 - AMC Publishing (Terms & Conditions - This public domain version of this expert system editor is made available for reproduction and distribution. This text file containing these terms & conditions must appear unaltered. All rights to copyright are reserved by AMC Publishing. Without violation of the above stated terms & conditions, this public domain version of the software may be freely copied. PC Clubs and Artificial Intelligence SIGs are especially encouraged to distribute this software to their members.) (This software and manual are presented "as-is" and without warranties as to performance or merchantability. This program is presented without any express or implied warranties whatsoever. Because of the diversity of conditions and hardware under which this may be used, no warranty of fitness for a particular purpose is offered. The user is advised to test the program thoroughly before before relying on it. The user must assume the entire risk of using the program.) TABLE OF CONTENTS ----------------- Diskette FILES LIST .................................... 1 The AVATAR I Expert System and Editor ................... 2 CREATING AN EXPERT SYSTEM ............................... 3 THE GOAL SYSTEM ......................................... 3 THE ATTRIBUTE-VALUE SYSTEM .............................. 5 TEXT FILES (.SOR FILES) ................................. 6 AUTOMATIC GOAL ENTRY FROM TEXT (.SOR) FILES ............. 9 THE RULE SYSTEM ........................................ 11 RULE SYSTEM LOGIC ...................................... 14 THE RUN-TIME SYSTEM .................................... 16 TEXT EDITING COMMANDS .................................. 18 ESSENCE AI'S PHILOSOPHY ................................ 19 EXPERT HELP IN CREATING YOUR AVATAR SYSTEM ............. 19 PROGRAMMER ACCESS TO THE DATA STRUCTURES ............... 19 Essence AI AVATAR I Editor & Run-time Expert System .... 20 The Essence AI AVATAR Expert System Pricing ............ 21 Diskette FILES LIST ------------------- AVATAR.EXE - The Essence AI AVATAR I Expert System Editor. EAIRHLP.TXT - The on-line help text. (Must be on the default disk.) EAIRHLP.IDX - This is the Help File Index. (The index for EAIRHLP.TXT and must also be on the current default disk.) README.TXT - This is this Manual. USRFIL.IDX - This holds the number that is incremented to keep track of successive inference engine runs and assigns a unique number to each one when the SAVED PROGRAM Option is Set. (See Text.) There is 1 very short Demo system: As all Toy systems, this demo is not intended to be considered as a complete example of a usable system, but it does illustrate the use of the Expert System Editor in an acutal working environment. You may learn a great deal by examining and modifying it as practice. AUTO - A Car Diagnostic Expert System. (This system only deals extensivly with the battery and starter system on a car that has the symptom of not starting. Other possibilities are seeded in the Attribute-Value system and are left to be expanded upon by the system designer as an exercise.) The files are named: AUTO.RGA AUTO.STR AUTO.SOR ENVIRONMENT ----------- Hardware: IBM PC and compatibles. Internal Memory (RAM): 256 K Minimum - 512K to 640K recomended. Monitor: Monochrome or Color. (Color screens can be set by user). Disk Configuration: Can run on a one diskette system, although, dual diskettes or a hard disk drive are recommended. Use: For anyone, non-programmer or programmer, that wants to create a personal, in-house, or commercially marketed Expert System. Note: The 'CONFIG.SYS' File should have the possibility of opening a fair number of files. The diskette version contains the following: FILES=20 -1- The AVATAR I Expert System and Editor ------------------------------------- The AVATAR I is the world's easiest-to-use artificial intelligence system. You communicate with the computer and create an expert system entirely in your most natural form of communication: ordinary, everyday language. No key words or obscure formulas need be learned. You do not have to program or know anything about a computer programming language. You don't have to understand about the computer or its operating system (except where the 'ON' switch is, of course). All rules are created in natural complete sentences and appear in a simple form that makes their use very clear. You are led through the creation of a system and, at each step, have on-line explanations and tutorial help available only one key stroke away. You may use your favorite word processor to write the text that makes up the body of knowledge that is the heart of the system. Therefore, you do not have to learn the commands of a new word processor. All of your entries in the editor lock you into the proper forms so you can't leave a menu until all details are correct and complete. We have found no expert system editor as simple to use that can create powerful, elegant expert systems which can be applied in your own personal context or marketed as a commercial product. The end users that might use your system product will have as much on-line help and explanation as you wish to write and will consider it the most accessable, easily used expert system. So, to sum up, the AVATAR I is a high efficiency expert system editor and inference engine that allows the person using it to create a complex, full capacity expert system by writing entirely in English (or any other human language as opposed to the more usual machine or programming type languages in which one normally communicates instructions to the computer). The editor fully directs your progress, step by step, through the creation of the knowledge base structure for an expert system. The Essence AI family of expert systems have four levels of complexity with this being the level 1 version. (Three other levels of the system are described at the end of this text.) The purpose of an expert system is to derive valid conclusions through the application of rules that will, during a run of the expert system program (the inference engine), if needed, query the user for further data. When a conclusion is reached (proven valid) then the associated information that is connected to that conclusion will be made available for display or printing. The heart of the AVATAR I system is the inference engine or that portion of the system that controls and directs the strategy of knowledge exploration during a run of the system. The method we use is a classical backwards chaining system with forward chaining capability. This means that the system looks at a list of possible conclusions and considers each one in an attempt to validate each in turn. This validation is based on the proving true of the rules of the system that are connected to those conclusions. (This is easy to understand by analyzing a few examples). There are only four terms that you need to understand. They are: GOALS - The conclusions that the system attempts to prove or validate. RULES - The collection of statements that prove or lead to the conclusions of the system. They are constructed of 'IF:' and 'THEN:' sections. ATTRIBUTE - VALUE Pairs - The part of the system that the end user sees and through which they communicate their answers. -2- CREATING AN EXPERT SYSTEM ------------------------- An expert system is created in 3 basic steps. (1) Create the Goals that the system will arrive at when the end user runs your system. These may have their text paragraphs attached to them by the Link menu and this text will come from the ASCII text (.SOR) file that you create with your favorite word processor. Each Goal must be in the 'THEN:' of at least one Rule to be a part of the system because only rules can set Goals to 'TRUE'. (2) Create the attribute-value groups that will be used in the system's Rules. These A-V groups should be the statements that you want to: (a) Set in the 'THEN:' part of rules. (b) Will be set by asking the user what values that given attributes should take. Explanations for the A-V groups and their queries are text paragraphs attached by the Link menu and this text will come from the ASCII text (.SOR) file that you create. (3) Create the Rules that will be used by the system at run time to attempt to validate Goals so that the text may be displayed or (in the higher levels of the system) designated actions may occur. Rules are the logic of the system and are the driving force of the run time system. Rules may lead to the consideration of other rules and so on in a backward chaining fashion. As the inference engine is an interpreter, when you add or change elements in the system, they are immediately ready to be run in the system. Work on a system usually moves in spurts as one element and the another is given the focus of attention. It is best to set the broad scope of the project in Goals and then perfect a select, small sub-set of Rules with their necessary Attribute-value groups and goals. Get this small section working to your liking and you will discover most of the important aspects of your system and the unique logic inherent in your subject. THE GOAL SYSTEM --------------- The list of Goals are the first element that one would usually consider when creating an expert system. The goals are the conclusions that you want the user of your system to arrive at or derive by proving valid or TRUE during the running of the inference engine. Goals are of two types, Terminal and Connecting. A Connecting goal may be used simply as a place holder to initiate a logic strategy whereas a Terminal Goal is, as the name suggests, a terminal conclusion type goal that is linked to some information that the system will display or print upon a successful validation of that Terminal Goal. Of course, Goals may serve a dual purpose in the system. With the use of the elements of this system, many complex and elegant information search strategies can be created. -3- The Terminal goals (what we usually mean when we use the word, 'GOAL') should be chosen as distinct, discrete blocks of information that can be reduced to single, stand alone ideas. They might be considered paragraphs that you would not, during the course of your system's use, want separated into smaller units. The criteria used to decide what information should be included in a Terminal goal and its accompanying text and where the separation should occur between goals is dependent on the nature of the information that is being structured in the knowledge base. The elements to consider are: natural division, completeness, grouping, order, and meaning. In keeping with good AI technique, we will consider the last element first. Meaning - Distinctions must be drawn between the definitions of the concepts: data, information, process, and meaning. Here we will restrict our deliberations to the realm of text communicated ideas, although, they may well be applied (with some restrictions) to graphic, auditory, and other forms of communication. Data is defined by the American College Dictionary as: "facts, figures, etc., known or available; information". Unlike the dictionary, I would like to separate the definitions of data and information. In the AI world, data shares a similar meaning to the common usage in that it is considered "facts and figures" which, in the computer, is represented electrically as logical symbols or characters. Data has a static relationship to the system. Until it has been activated by a process, either organized to simply report the data or interacting with some process that will lead to an alteration or creation of new data, the data remains static. For data to become information, it must be structured dynamically, acted upon in a meaningful manner or be processed. The process used by the expert system to change static state data into information is through completing a proof of the validity of a goal. The goal, then, is a result the system tries to arrive at with the proving 'TRUE' of the conditions contained in a rule. The conditions in this instance are the 'IF:' part of any rule that has the connecting goal in the 'THEN:' part of the rule. (See the "RULE SYSTEM" Examples for clarity). Thus, a goal is data that has become information by virtue of the meaning imparted to it through the rule which validates it. We will not, with this present inference engine, deal with the proof of 'FALSE' of a goal as this would require more careful handling of the rule structures and violate our proposition that this be the simplest expert system to use. Because actions or significant meaning might be attached to the equivalent of a goal being 'FALSE', that condition of the goal should be declared as a distinct goal. An example from the Automobile Diagnostic might be: Goal 1-An Electrical Problem; Goal 4-Definitely Not an Electrical Problem. The Natural Division - is the line along which a subject separates its elements or goals into distinct entities to be proven. Some subjects are more conducive to such division. The obvious examples are systems that have goals made up of more or less equal elements to choose between and the purpose of the system is to make that selection. For example, a program that deals with choosing of your ideal house plant would have obvious natural divisions of equal weight goals to consider; the end goals being the collection of the names of all the possible house plants from which the system would choose. -3- In contrast, a system that diagnoses problems with an automobile or the human body will have a heterogeneous set of problems whose solutions would include both the simplex and the complicated. The latter is approached easily by considering the solution paths terminating at differing levels on a pyramid. This may include rules that prove goals that in turn become conditions in the 'IF:' parts of other rules proving more goals further below them in the pyramid. Completeness - in the above instance of a complicated goal system should be approached with care. The Top-down approach is a good method to employ when the body of information to be systematized is composed of diverse goals. This is implemented by defining the broad categories that cover the subject as a whole. In a car diagnostic system that might be the top goal definitions of the (1)fuel system, (2)the electrical system, (3)the engine, (4)the power train - transmission, (5)the wheels & brakes. Then, each element of each category is in turn separated into its discrete goals and so on until you reach the fundamental parts that cannot logically be reduced further. Again, a series of pyramids held up by pyramids. The Grouping and Order are maintained by applying the method of Top-down analysis that has been described above. The order that the goals are listed in will determine how the system accesses them. It is imparitive that the goal list is structured for the most efficient access to the data. Goals that, if not proven 'TRUE', would invalidate an entire group of other goals should be determined at the head of the goal list. For example, a system dealing with the human body would probably like to ascertain if the person being diagnosed is female or male. This obvious distinction, if determined early, would lead to an efficient use of the system by invalidating (setting as unprovible) all the goals that would deal with the anatomy of the sex not being considered in a given system run. Example: a rule such as, "IF: Sex is female. THEN: Birth information." By placing a goal with far reaching effects as the first statement of a rule, you would effectively block the system from unnecessary computation in seeking solutions to goals. As every expert system has its own divisions, categories, unique problems and structures, and its own internal logic, you can rarely (unless its a very small system) lay out the whole goal list before hand. Our best suggestion is to let the system evolve by setting down the broad strokes and then taking a small portion and completing its logic. You will, by this method, discover the internal dependences, constructions, and logic that is inherent in and unique to your subject and its information. The most fascinating aspect of AI system creation that we have found is that, unlike conventional programming projects which can be all quite similar, the construction of an expert system always poses new and unusual challenges to overcome. Each body of information must reveal its secrets to you for your system to achieve robust elegance. -4- THE ATTRIBUTE-VALUE SYSTEM -------------------------- The attribute-value (A-V) group is the structure that is most active in communicating information throughout the system. An attribute is a unique property of an object or concept contained in the data of an expert system. A value defines a state or instance that a given attribute may take. For example, a car may be defined by its various attributes such as: Color, Make, Model, Year, Cost, Length, Country of Manufacture, etc. Under the Attribute - "The Color is" - the values might be: "Red, Black, Mauve, Burgundy, Two-toned Blue and Pink". In a more abstract example like a concept, the attribute might be - "The State of Mind:" - and the values might be: "Happy, Ecstatic, Blissful, Depressed, Apathetic." The point being an object is defined by the properties or attributes which it has and a given instance of an object or occurrence of a concept is defined by exactly what values that these attributes take. An attribute in a given instance may have: (1) no valid values that can be attached to it; (2) one value that can be connected; (3) multiple values attached. The formal connecting of an attribute to a value is called an instantiation and an attribute is instantiated to a value. In less formal terms, we might say that an atribute TAKES a value. A-V groups, to be easily understood by users and in keeping with our ideal, may be created in either a subject-object sentence relationship or as a multiple choice structure. The English sentence idea would be like: The sides of the shape are of equal length. of unequal lengths. curved. curved and straight. unknown. With 'The sides of the shape are' being the attribute and the 5 values being: (1) of equal length.; (2) of unequal lengths. (3) curved. (4) curved and straight. (5) unknown. The main form of communication between the user at run-time and the expert system is through the choosing of the attachment of values to the attributes. The attributes and values can be paired in two ways: (1) The attribute-value group that, during the course of the rule system attempting to prove a goal TRUE, has been found to not be in the 'THEN:' of a rule and is presented to the user for selection of valid pairs. This is how the user is queried by the system. The system asks the user to set the connections between a given attribute and its values only once per system run. In other words, if another rule comes up that has a condition (an 'IF:' statement) that includes an attribute that has been previously queried, the system remembers that the user has already answered which values should be set to that attribute. If the attribute-value pair in question is one that the user has happened to previously chosen, that statement is set to TRUE, else it is FALSE and invalidates that rule. A 'NOT' type statement is TRUE if the attribute-value (A-V) pair is or has not been set. -5- (2) An attribute-value pair may be in the 'THEN:' part of a rule. This will set the connection (instantiation) between the designated attribute-value pair. This may occur even if the attribute-value group that the pair belongs to has been displayed to the end user for selection. So, additional A-V pairs may be added to the system during a run by validated rules even if the user has been previously queried. The attributes may have a three line query displayed along with them at run time if you feel that the A-V group needs more on-line explanation then is carried implicitly in its elements. A further, in-depth explanation may be set in the text file under a block of data with the heading, '##a___", (see the topic - "TEXT FILES (.SOR FILES)"). The Maximum - Minimum value Choices are defined to allow the system designer control over how many A-V pairs the user can set if, during a run, the user is queried. The Minimum can be set to zero if no A-V pairs is a valid response. Look at the sample expert systems if you still have questions. By running them a few times, all these relationships will be clear. TEXT FILES (.SOR FILES) ----------------------- The text files that link to the various Attribute-value groups and Goals are created by you as ASCII files using your favorite word processor. Each word processor has a method to create an ASCII file. For those not familiar with this type of file, this is the universal file and character format that is used by programmers as they prepare programs for input to various computer language compilers. This kind of file format may be called by different and conflicting type designations depending on the word processor that you choose. They may be called 'text' files, 'non-document' files, 'dump' files, and so on. Usually it will be made clear in your word processing manual as to how one goes about creating an ASCII file. If you have trouble finding the correct commands to create ASCII files, we would first direct you to the store you purchased the software from and, if you have exhausted all local sources, you are welcome to contact Essence AI-AMC. We may be able to put you on the right track as we have experience with many different word processors. The lines of text cannot exceed the maximum of 400 lines per block of text. If you need this limit raised, contact Essence AI for a modified version of the program. Exceeding the maximum limit will result in an error. You may divide the text into 400 line blocks and attach to a group of Goals if you need very large text blocks. The syntax of a linkable data file that you create has a single form used by all the commands and data types. In the first and second column are pound (sharp) signs - the '#' character. So in the first two columns are '##' followed by a type designator (symbolized by 'g' below) and that is followed by a number if it is a designation that takes a number. An example would be: ##G123 Which breaks down to '##' starting in the first column followed by the type designator, (in the sample, 'G' for Goal is used), followed by the Number '123' which is the corresponding goal Number. The type designator may be in UPPER CASE or lower case - either are recognized. -6- The 5 type designators are: 'S' (or 's')= Source file number. This is the file identification number. This present configuration will allow the linking of up to seven (7) text files. The reason for multiple text file linking to the expert system knowledge base is that this method allows one to create text that exceeds the size of one diskette (370,000 bytes on an average diskette). Therefore, such an expert system can be used on systems that might have only one or two diskette drives as opposed to only hard drives. If you ship a multiple diskette system, it is best to include a file set program that will link all the text files in case the user has a hard drive. Essence AI has this add-on software available. 'G' (or 'g')= Goal. To be displayed upon a Terminal Goal validation at run time. This text is the only candidate for multiple diskette systems as the Goals' data is only displayed once at the end of the inference engine run. 'A' (or 'a')= Attribute-Value. To be displayed during run time if the user requests an explanation of the Atribute-Value choices being presented on the screen by pressing the 'F-3' key. The explanations should be on the first file diskette that has the same file name as the system's '.RGA' and '.STR' (system created) files. They should, if at all possible, be limited to this file so the user does not have to do disk swaping during a system run. 'U' (or 'u')= Use explanation text. This will be displayed to the user at run time as the first text screen that the user will encounter. Here is where you may tell the user what the system is about, how to use it, what they will see in the Attribute-Value screens. The Use explanation should be on the first file diskette that has the same file name as the system's '.RGA' and '.STR' (system created) files. 'F' (or 'f')= Final explanation text. This will be displayed to the user at run time as the text screen that follows the system run of the Rules and precedes the display of the user answers & the validated goals and goal linked text. Here is where you may tell the user how the conclusions will appear and what they will see in the Attribute-Value choices they made. The Final explanation should be on the first file diskette that has the same file name as the system's '.RGA' and '.STR' (system created) files for ease of use. (The syntax of a linkable data file is shown on the next page) -7- The syntax of a linkable data file is as follows: [Comments in brackets - not to be entered] [number as defined in the edit system - must match system use no.] [Example file starts after '------' line: -------------------------------------------------------------------- ##S1 [Sdisk number 1 to 7; maximum 7 diskettes per system = 2 1/2 Mb] ##G123 [5 types; 'g'=goal, 'a'=attribute-val, 'u'=use explanation text, 'f'=final explanation text, 's'=source file number] TITLE OF SPECIFIC GOAL Text that explains goal..... So on and so forth......... Etc., etc........... [This part is the information that will be displayed to the user when the runtime system is used.] [ This is the text that is being linked to the above defined system element with the defined Type (e.g. - 'g' is a GOAL) and the defined NUMBER (e.g. - 123 in this example is Goal Number 123) with all the text that follows the - '##' TEXT CODE HEADING - that will all be linked up to the next data text block that will start with the next '##' . Each file to be LINKED must start with a '##S' followed by the A VALID UNIQUE NUMBER that will be associated with that 'FILENAME.SOR' File. No two files LINKING to the same expert system can have the same ID NUMBER. The Maximum number of diskettes that can be linked to an expert system with this present configuration is 7, a reasonable number for a usable expert system. In a hard disk system, the expert system may LINK to the whole disk if so desired.] ##a12 [12=number as defined in the attribute edit system ] ATTRIBUTE-VALUE PAIR TITLE This and That......... [ This is the text that is being linked to the above defined system element with the defined Type (e.g. 'a' is a ATTRIBUTE) and the defined NUMBER (e.g. - '12' in this example is Attribute Number '12') with all the text that follows the '##a12' that will all be linked up to the next data text block that will start with the next '##'. Each Data Block Like this to be LINKED must start with a HEADER that has in its FIRST COLUMN '##'] [There are two special terminal blocks of data that are available for the system designer to use to customize the runtime system. They are the 'use' text block and the 'final' text block. The 'Use' block will appear as the first screen of data after the preliminaries of name & password have been entered. Here, you may tell your user in your own words how to use the system, what the strategies are, what the purpose is, etc. The 'final' text block appears after the run and before the display of the Attribute-Value Pairs and Goal validations & valid text data. Here you may describe how to use the final data, what the options are, etc.] [ Syntax of the User System Pre-Run explanation Block ] ##U [Identifies this terminal block as the user use explanation] This system is for.....etc,etc........ so on and so on................. -8- (The syntax of a linkable data file continued from previous page) [ Syntax of the User explanation Post-Run Block ] ##F [Identifies this terminal block as the user final explanation] Final text of specific expert system This next section is for.....etc,etc........ so on and so on................. AUTOMATIC GOAL ENTRY FROM TEXT (.SOR) FILES -------------------------------------------- The linking system in the expert system editor has the ability to automatically transfer goals into the system within a restricted context. If a goal already has a name and number, that is, it exists in the system, the linking process will simply attach the goal text file pointers and nothing else. If the system finds that the number of the text data assigned to goal is a previously deleted goal, it will enter the first line of text that it finds into the editor system as the goal name for that corresponding empty goal position. If the goal number is higher then any previously entered goal numbers, the system will try to SEQUENTIALLY add the goals. I emphasize that the goals higher then the existing goal number, in order to be automatically entered, must be sequentially entered or else the auto entry will abort. For example, If your previously entered goal list looks like: The sequence in which events occur as the run-time system is brought up is as follows: 4 8 9 1 2 3 [ ] 5 6 7 [ ] [ ] 10 11 12 - With '12 ' being your highest existing goal number and previously deleted goal positions of goals '4', '8', and '9'. If you entered text file blocks that had the numbers that looked like the following: [Top of text file] ----------------------------------------------- ##s1 [This is file number 1 ] ##g3 GOAL NUMBER 3 Text that is attached to goal number 3............. So on and so forth................. ##g4 GOAL NUMBER 4 Text that is attached to goal number 4............. So on and so forth................. (The syntax of a linkable, automatic Goal entry data file is continued in the next page) -9- (The syntax of a linkable, automatic Goal entry data file is continued from the previous page) ##G9 GOAL NUMBER 9 Text that is attached to goal number 9............. So on and so forth................. ##g13 GOAL NUMBER 13 Text that is attached to goal number 13............. So on and so forth................. ##g14 GOAL NUMBER 14 Text that is attached to goal number 14............. So on and so forth................. ##G15 GOAL NUMBER 15 Text that is attached to goal number 9............. So on and so forth................. ##g17 GOAL NUMBER 17 Text that is attached to goal number 17............. So on and so forth................. ------------------------------------------------- [End of text file #1] The linking process would link the text to goal number 3 because it already exists. Goals '4' and '9' would be automatically entered and would receive the names 'GOAL NUMBER 4' and 'GOAL NUMBER 9' because these are the first lines of text the system encountered. Goals '13' to '15' would be also automatically entered because, although they exceed the highest goal number, they are sequential in the text file. The system would detect an ERROR in attempting to process goal '17' ('##g17') because it is not in sequential order and is above the highest existing goal number. If you do not wish to use auto entry of goals, enter all goal names in the editor, first, before linking text. Remember, if the system aborts upon finding an error, it will not automatically SAVE the file. If you wish to do so you must use the file save menu to do so by hand. In fact, every once and a while, you should perform a 'file save' from the menu because all work is done in main memory and can be lost if there is a fatal system error. In Conclusion, the concept of the text file system and linking is hard to understand by just reading about it. If you look at the example text (.SOR) files and note their construction, I believe that all the mystery will be easily cleared up. -10- THE RULE SYSTEM ---------------- The Rules are the structure that determines how the system will run. They are the pyramid of knowledge that Validates the Terminal Goals (usually just called Goals) - the ultimate conclusions of the system. The only logic elements in the system that are defined by the system designer are entered in the construction of Rules. Backward chaining is the main method that the system uses on the Rules in its search to set Goals valid. To illustrate the use and construction of rules, we will examine them in relation to Attribute-Values, Goals, and The Run-time system. Backward chaining looks at a conclusion (as: THE SHAPE IS A SQUARE) and then looks for a rule that can be used to prove this conclusion TRUE like: RULE #1: IF: (1): The sides are of equal length. (2): The number of sides is four. (3): The corners are right angles. THEN: (1): THE SHAPE IS A SQUARE If all the conditions set forth in the 'IF:' part of this rule can be proved true then the conclusion 'THE SHAPE IS A SQUARE' is proved TRUE or valid and the data associated or linked to this 'THEN:' conclusion will be displayed. There is a logical 'AND' assumed between the numbered Rule statements demanding all must be satisfied for the 'THEN:' statements to be set. To illustrate backward chaining, if the system also contained a rule such as: RULE #2: IF: (1): The shape has corners. (2): The angle formed at the corners are all 90 degrees. THEN: (1): The corners are right angles. In an attempt to prove the conclusion 'THE SHAPE IS A SQUARE' in the 'THEN:' part of the Rule #1, the system would find that the condition or statement number 3 in rule #1 '(3): The corners are right angles. ' had a rule connected with it that could prove it to be true so, in an attempt, to validate the third statement of rule #1, Rule #2 would be called and this is a classic example of backward chaining. If no rules were connected to the statements ' (1): The sides are of equal length.' in Rule #1 or '(1): The shape has corners.' in Rule #2 then the person running the program is queried as to what the case is relative to these statements. -11- In an attempt to validate Rule #1 - Statement (1), the system may ask the user the question: ------------------------------------------------------------------------ The sides are (Choose what most closely describes the shape that you are trying to identify relative to the shape of the sides that make up the sides of the object). +of equal length. of unequal lengths. curved. curved and straight. unknown. ------------------------------------------------------------------------ If the user chooses the first selection (marked with a '+' (plus sign) to denote the answer, then Rule #1 - Statement (1), will be marked as TRUE and the system will continue on to attempt to validate Rule #1 - Statement (2) in the 'IF:' or conditional portion of the rule. To be redundant, when all three conditions of Rule #1 are proven to be TRUE then, and only then, is the statement '(1): THE SHAPE IS A SQUARE' set to TRUE or valid (keeping in mind that there may be other rules in the expert system that have the statement 'THE SHAPE IS A SQUARE' in the 'THEN:' part of their rule). Goals may be set to query their connected rules only until the given Goal is proved valid. Then the chain of rules for that Goal is abandoned. Goals (conclusions) also can be set to test all rules connected to them, usually for the purpose of gathering some strategic information that will be used further in the system. The meta-structure or control of the order that the system will use in its search for validation of Goals is set by the order of the list of goals. So, you may control the system's search strategy by ordering the Goals in the order that you want the rules connected to them to be accessed. The order of the accessing of the rules connected to a given Goal is random if there are multiple rules created to validate the same Goal. If you want a specific order to the rule accessing, you may create it with a connection to a specific Goal ordering that can be paired in the 'THEN:' part of the rules in question. Testing will make this clear. The Attribute-Value section of the system is the portion that the user sees the most of during a run. For example, as in RULE #1:, the attempt to find a validation of the 'IF:' statement #1 - (1): The sides are of equal length. -12- Given that there is no rule that connects the attribute 'The sides are' to the Value 'of equal length.', the System inference engine asks the user a question on the display, soliciting a response such as: ------------------------------------------------------------------- The sides are (Choose what most closely describes the shape that you are trying to identify relative to the shape of the sides that make up the sides of the object). -------------VALUE CHOICE: MINIMUM #<1> - MAXIMUM #<1>----------- +of equal length. of unequal lengths. curved. curved and straight. unknown. ------------------------------------------------------------------- The attribute 'The sides are' can connect to any of the 5 values: 'of equal length. of unequal lengths. curved. curved and straight. unknown. ' that are put forth as possible values that the Attribute can take. Each attribute-value group has a designation of: 'VALUE CHOICE: MINIMUM #<1> - MAXIMUM #<1>' which tells the user how many choices are requested. In the above example, the user must choose one selection and only one selection. Therefore, the attribute - 'The sides are' is, in this instance, limited to connecting to only one of the values displayed. An attribute such as 'The color of the flag is' might be set to a collection of values like 'red', 'white' and 'blue'. So, an attribute may take as many values as the system designer has stipulated. There is a system limit of 15 values maximum because this allows for a complex value that may take the entire width of the video display to write and still keep to one screen without the necessity of scrolling. More then 15 choices for the same attribute is somewhat overwhelming to the user, therefore we limit the system to displaying a total of 15 values at a time. If more choices are needed for a given attribute, it may be split into 15 value chunks. When a Goal is validated, the system looks for a linked text file to display as a conclusion. This text file is linked to those various Goals, Attribute-Value groups that they have been defined for as well as system Use explanations. During a system run, if the user presses the 'F-3' function key, the definitions of the attribute-value group on the screen at that time is displayed. -13- RULE SYSTEM LOGIC ----------------- The logic of the system is simple, first order, single level logic. The two statement connectors are 'AND' and 'OR' and no others. The statements in the 'THEN:' portion of a Rule are connected only by the assumed 'AND'. This is assumed on any statement also in the 'IF:' portion that does not have an explicit 'OR' displayed in it. A statement in the 'IF:' part of a Rule may be negated with a logical 'NOT' that is entered by entering a '-' (minus sign or dash) before the selection number but after an 'OR' when creating Rule statements. The 'NOT' type statement is proven valid by the system attempting to prove the attached Goal or Attribute-Value pair valid or TRUE and, failing to do so, validate the 'NOT' statement. The 'THEN:' portion of a Rule can have statements connected only by the implied 'AND' and these 'THEN:' resident statements can be, in the case of Goals, only valid (TRUE) or unproven. 'NOT' is not considered as a valid case for a 'THEN:' stated goal. If a goal is not used in a rule, it cannot be accessed by the system and is therefore useless. All Goals must be connected to the 'THEN:' of some Rule in the system (and, of course, they may be used as needed in the 'IF:' parts of Rules). Attribute-Value Pairs, as statements, may appear in 'IF:' or 'THEN:' sections of Rules and need not appear in the 'THEN:' of a rule to be accessed by the system. If an Attribute is queried by asking the user of the run time program as to what Value is to be assigned to it, the system will only question the user once per relevant Attribute-Value group. That is, if a subsequent Rule uses the same Attribute with a different Value, the system will remember that it has asked the user for what Attribute-Value Pairing is valid and will use whatever information is stored from that query of the user to try to validate the present Rule statement it is currently encountering. In creating Rule statements, an Attribute-Value Pair statement is created in response to the screen prompt: "VALUE: MIN:## MAX:## OR='OR' NOT='-' V# <-': " OR='OR' - If a number is preceded with the word 'or' (or 'OR') the statement will be tested in a "logical or" fashion with the statement preceding it. The first statement in a rule cannot be an 'or' type for the obvious reason that no statement precedes it. There is a set membership relationship between 'or' type statement groups. If any statement in an 'or' group is set to TRUE or VALID then the group is considered valid and the remainder are not tested as is consistent with the system's philosophy of logical efficiency. -14- Example of Attribute-Value 'OR' Group: RULE #123: IF: (1) The Flag color is Red (a 3 statement { (2) The Flag's design contains { Stars 'OR' { (3) OR The Flag's shape is { a rectangle group) { (4) OR The Flag is used in { America (5) The Flag color is Blue (6) The Flag color is White (a 2 statement { (7) The flag's designer was { Bettsy Ross 'OR' group) { (8) OR The flag originally had { Thirteen stars (9) The Flag color is NOT Black THEN: (1) The Flag is American Explanation: If statement 2, 3, or 4 is true then the Rule can be considered valid if the other statements in the rule (including the second 'or' group of statements 7 and 8) are set to TRUE or VALID By other Rules or User Queries asked at run time. NOT = '-' A value number preceded with a dash (or negative sign) is interpreted as a NOT statement or negation of the Attribute- Value Pair. The system will prove a negative by attempting to prove it Positive and if that fails, the Negative will be considered to be TRUE or valid. An example is statement 9 above. <-': - Entering will send you back to the sub-system to choose another attribute if you wish. In creating Rule statements, a Goal statement is created in response to the screen prompt: "GOAL: OR='OR' NOT='-' ID G# , List, or <-' to exit: " OR='OR' - If a number is preceded with the word 'or' (or 'OR') the statement will be tested in a "logical or" fashion with the statement preceding it. The first statement in a rule cannot be an 'or' type for the obvious reason that no statement precedes it. There is a set membership relationship between 'or' type statement groups. If any statement in an 'or' group is set to TRUE or VALID then the group is considered valid and the remainder are not tested as is consistent with the system's philosophy of logical efficiency. -15- Example of Goal 'OR' Group: RULE #123: IF: (1) The Flag color is Red (a 3 statement { (2) The Flag's design contains Stars 'OR' { (3) OR The Flag's shape is a rectangle group) { (4) OR The Flag is used in America (5) The Flag color is Blue (6) NOT The Flag color is Black (a 2 statement { (7) The flag's designer was Bettsy Ross 'OR' group) { (8) OR A Thirteen star Flag (9) The Flag color is White THEN: (1) An American Flag Explanation: If statement 2, 3, or 4 is true then the Rule can be considered valid if the other statements in the rule (including the second 'or' group of statements 7 and 8) are set to TRUE or VALID By other Rules or User Queries asked at run time. NOT = '-' A goal number preceded with a dash (or negative sign) is interpreted as a NOT statement or negation of the Goal. The system will prove a negative by attempting to prove it Positive and if that fails, the Negative will be considered to be TRUE or valid. An example is statement 9 above. THE RUN-TIME SYSTEM ------------------- The Run-time system is the inference engine with which the user interfaces with the expert system's rules, goals, and attribute-value groups. This is the actual exploration of the rule base in search of valid goals. The inference engine exists as a stand-alone, royalty free program when purchased with one of our commercial models of the expert system editor. The following is the sequence of screens and events that take place during a run of the inference engine. The system title screen appears. There is the option on our later versions of the program to create a custom graphic first screen. The system then has an optional request of name, password, and user run-time file save number displayed. The option for setting how the system will run is in the editor's data menu. The USE text in the '.SOR' file will be next so you can see why it is important that this text be in the main '.sor' text file. The inference engine will then proceed to attempt to validate goals by examining rules that are linked to the various goals. If the system reaches a point where it needs information to continue, the user is requested to indicate what values should be selected to be attached to attributes. The attribute-value groups are, therefore, the part of the system the end user sees the most of during the run of the rules. -16- While the rules are being considered, the user is allowed to, depending on the options set in the data file, display explanations, the rules being considered, the use of the system, and help files that tell how to enter one's selections. After the engine completes the validation of all the possible goals, than the final text data defined by the system text file is displayed followed by the list of the attributes and the values that have been selected by the user and set by validated rules. The user is now asked to select the options of file disposition that that they desire. That screen looks like: "(1) DISPLAY EVALUATION on Video Output" "(2) PRINT Valid TEXT on Printer" "(3) WRITE EVALUATION Run File to DISK Memory" "(4) EXIT" "SELECT 1 to 4 Evaluation Options:" You may choose any combination of options including all in this selection of validated data presentation methods. They will be presented, if chosen, in numeric order. (1) - DISPLAY EVALUATION on Video Output will send the data to the video display. (2) - PRINT Valid TEXT on Printer will send the data to the printer. The printer must be online or a runtime error will occur. (3) - WRITE EVALUATION Run File to DISK Memory will create a file on the default disk drive. If this option is not chosen, this program run will be deleted. So, if you ever want to review this session or you have only partially completed a run and will want to continue in the future, this option must be chosen. (4) - EXIT. If you choose "(1) DISPLAY EVALUATION on Video Output", the following screen will appear: "(1) DISPLAY FULL Data on Video Output" "(2) DISPLAY Valid Names for SELECT Video Output" "(3) EXIT Display" "SELECT 1 Option:" (1) - DISPLAY FULL Data on Video Output will output in order each valid data set. (2) - DISPLAY Valid Names for SELECT Video Output will display a list of the validated data so that you may selectivly review what you wish. One word of caution: if you are running a diskette system with multiple data diskettes, jumping around in the list may cause many system requests for excessive diskette swapping. The order of goals displayed should be set in an orderly manner with the data on the diskettes. (3) - EXIT Display will exit without displaying anything, but will query you about saving a disk file of this program run. A separate diskette should be used for this if you are running a diskette system. -17- After the user has viewed and disposed of the conclusions that the given run has produced, they will be given the option to save the particular run, if the option to do so is set. That screen will say: "Do you want to SAVE a DISK COPY of this evaluation?(y/n):" "WARNING!!! Answering \'n\' (NO) will TOTALLY DELETE this RUN FILE!" If you enter 'y' a copy of this program run will be saved in a file that has the Name, Password, Pathname you entered at the beginning and the run number that, if this is a new run, was assigned by the system or, if it was a recall of a previous run, that previously assigned number. If you enter 'n', the system run files, even if this is a recall of a previous run, will delete the runtime file that exists. At this point, the run of the inference engine is complete and the system will exit if it is run on the stand-alone module or to the menu if it was called from an editor menu. TEXT EDITING COMMANDS --------------------- TEXT EDITING - The commands that are used in all character data entry are: Cursor positioning arrows on the right hand number pad on the key board. ( Cursor left: on number '4' = "<--") ( Cursor right: on number '6' = "-->") The Back space arrow '<-' will delete the character to the left of the cursor. The 'Del' (delete key) will delete the character directly above the cursor. Typing a character will insert it at the position where the cursor is. 'Enter', 'Return', (sometimes labeled "<--'" ) will leave the character phrase editing line as will hitting the 'Esc' (escape) key. F1 - will display the first level help screen (this may be the only help text for a given position). This tells the Key commands meaning. F2 - will display the second level help screen in the run time system as it is defined. This tells the meaning of what the position is requesting and how it will be used. If you are editing a pre-existing character string and the first key you hit is a printable character, the entire string will be cleared. So, if you want to edit only a few letters or words in a character string, you must hit a non-printable character as the first character such as a cursor positioning arrow to keep from erasing the entire string. These character string editing rules are valid in the writing of Goals, Attributes, Values, and the Attribute Query. -18- ESSENCE AI'S PHILOSOPHY ----------------------- It is our intention to create systems that are of the highest quality one can find for a cost that is reasonably set so all may explore the wonders of Artificial Intelligence. Our most important element that we build into our systems is ease of use and simplicity of design. If you are able to create an expert system with a little study of this manual and the on-line, context-sensitive help windows that are attached to every entry point in the editor, we have fulfilled our goal. We have a continuing Research and Development Division that is dedicated to adding on to and creating new and expanded versions of our existing products and develop new systems that explore the frontiers of AI and related areas of computer science such as intelligent database systems and natural language processing for the Personal Computer. We will periodically be introducing new products as they leave the testing phase. Above all, we are User-motivated. We are open to any requests or suggestions you might have and our commitment to quality is paramount. If you have any ideas how we might improve or add to our existing products, please do not hesitate to communicate with us. We also offer this: For every new idea that has not been previously communicated to us or initiated by or own R & D department, if we use said idea in a system, we will send a free copy of the new system to the person who was the first to send in the idea. This also goes for any errors that you may discover in the system. We intend that the systems be bug-free and wish to repair anything that may occur. Our standing commitment to those who have purchased systems from us or through our authorized distributors is that we will periodically make available updated versions of a given release of a product on a modem-accessed system at our facility for you to down load new versions if such action becomes necessary. This applies only to repairs and not new system augmentations and additions other then as stated above. Please tell us your ideas of how we may better serve you and share your systems with others. If you create a system that you feel has commercial value, we will review it and, if it is found to be consistent with the type of systems that we offer, we may consider a royalty-based publication agreement with you. EXPERT HELP IN CREATING YOUR AVATAR SYSTEM ------------------------------------------ We are in contact with professional knowledge engineers that are thoroughly familiar with the AVATAR system and, if you find need of such a person's services, we will facilitate putting you in contact with them. PROGRAMMER ACCESS TO THE DATA STRUCTURES ---------------------------------------- Essence AI-AMC has made the AVATAR System Data Structures public domain to allow programmers access to the system files if they wish to implement their own custom inference engines and search strategies. Also, access to popular Data Base and Spreadsheet programs as well as confidence factors may be installed. Write or call Essence AI-AMC for details. -19- Essence AI-AMC AVATAR I Editor & Run-time Expert System ------------------------------------------------------- This is a brief set of printed instructions on how to call the system. We hope you will feel free, if you have questions, to contact: Essence AI-AMC Telephone: (503) 644-2438 P.O. Box 1420 Beaverton, OR 97075-1420 The use and vocabulary is described in 'readme.txt', this ASCII file of instructions that you may print out with the DOS command 'PRINT' or read with the 'MORE' command. (The data that you enter is underlined with '------') (To PRINT, at a prompt, type:) >PRINT README.TXT ---------------- (To READ, at a prompt, type:) >MORE TYPE README.TXT --------------- A preliminary consideration is that your SYSTEM BOOT disk from DOS must have a 'CONFIG.SYS' file with the commands defining numbers of FILES and BUFFERS as: FILES=20 BUFFERS=8 TO BRING UP THE SYSTEM: (At a prompt, type:) >AVATAR filename --------------- or >AVATAR ------ The filename must be 8 characters or less. If it is to go onto the 'b:' drive, the full name, 'B:filenm' must be 8 characters total. The system creates two files 1) 'filename.RGA' & 2) 'filename.STR' while you must create a file called 'filename.SOR' with the syntax as described above. NOTE!! - To Run the SYSTEM, there MUST be Enough space to open a file on the Default disk. -20- The Essence AI-AMC AVATAR Expert System Pricing ----------------------------------------------- (NOTE - Prices are subject to change without notice) The AVATAR I Expert System Capable of holding up to 10,000 Rules along with a User Run-Time inference engine that may be distributed royalty free with your expert system definitions, Expanded Manual and Tutorial. COST.................$35.00 (Prices include domestic shipping) The AVATAR II Expert System Capable of holding up to 10,000 Rules along with a User Run-Time inference engine that may be distributed royalty free with your expert system definitions, Expanded Manual and Tutorial, access to DOS and the running of external programs. The importing of data from other files. Variables with character entry. COST.................$55.00 (Prices include domestic shipping) The AVATAR III Expert System Capable of holding up to 10,000 Rules along with a User Run-Time inference engine that may be distributed royalty free with your expert system definitions, Expanded Manual and Tutorial, access to DOS and the running of external programs. The importing of data from other files. Variables and math functions. A report generator that allows you to customize a printed output after a system run. COST.................$115.00 (Prices include domestic shipping) For all non-domestic orders, add $10.00 (U.S.) for shipping. Address all communication with Essence AI to: Essence AI-AMC Publishing Telephone: (503) 644 - 2438 P.O. Box 1420 Beaverton, OR 97075-1420 -21- ----------------end-of-author's-documentation--------------- Software Library Information: This disk copy provided as a service of The Public (Software) Library We are not the authors of this program, nor are we associated with the author in any way other than as a distributor of the program in accordance with the author's terms of distribution. Please direct shareware payments and specific questions about this program to the author of the program, whose name appears elsewhere in this documentation. If you have trouble getting in touch with the author, we will do whatever we can to help you with your questions. All programs have been tested and do run. To report problems, please use the form that is in the file PROBLEM.DOC on many of our disks or in other written for- mat with screen printouts, if possible. The P(s)L cannot de- bug programs over the telephone. Disks in the P(s)L are updated monthly, so if you did not get this disk directly from the P(s)L, you should be aware that the files in this set may no longer be the current versions. For a copy of the latest monthly software library newsletter and a list of the 1,000+ disks in the library, call or write The Public (Software) Library P.O.Box 35705 - F Houston, TX 77235-5705 (713) 665-7017